home *** CD-ROM | disk | FTP | other *** search
-
- The Mouse Detective :-)
-
- This is an incomplete program for mouse detection. The idea is to
- use it in some kind of dialog that says: try to move your mouse and
- click on the OK button. If this doesn't work, enter return [the
- keyboard focus is on cancel].
-
- Use it like this:
-
- $ ./mdetect -v
- Found the following devices:
- /dev/ttyS1
- /dev/ttyS0
- /dev/psaux
- [start moving mouse]
- microsoft: 105 102
- logitech: LM -27 27
- microsoft: L 6 -43
- logitech: LM 93 191
- microsoft: 7 -7
- Detected microsoft mouse on /dev/ttyS0
-
- You can see it switching between logitech and microsoft mode until it settles
- on microsoft mode. Invoking it without the -v switch disables all output
- except for the `Detected ... mouse' line.
-
- Currently, the following mice are reported:
-
- psaux PS/2
- mousesystems MouseSystems compatible
- microsoft Old Microsoft protocol
- logitech Some (old) logitech mice
- mouseman MouseMan (microsoft with 3/4 packet extension)
-
- Here's a framework that I think might work
-
- 1. Start the mouse detection program
- 2. Start X server, display dialog
- 3. User starts moving the mouse
- 4. Detection program tries to understand what the mouse
- tries to say (this is stage1). It should arrive at a
- decision within 1 sec.
- 5a. Detection program has decided on a driver. Enters stage2,
- where it writes the mouse packets it received into a fifo
- (but now, in a mouse-type independent packet format). This is
- basically what gpm -R does.
-
- Pointer starts to move on the screen.
-
- 5b. Detection Program wasn't able to detect mouse type. It doesn't
- do anything. Pointer doesn't move, user has to select mouse
- manually.
-
- NB: How does XF86Config set the mouse type? I assume there's an X
- extension? If so, in step 5, we can also tell the X server what mouse
- to use (if we know what to use), and exit. This is a lot better than
- the fifo approach.
-
-
-
- Mode of Operation
-
- What the program does is open all available devices for reading.
- Whenever it gets a byte, it lets all drivers (currently psaux, microsoft,
- logitech) have a look at it. If the driver can make sense of the
- packet, fine. If any driver is able to successfully decode 20 mouse
- packets in a row, it is considered _the_ driver.
-
- Serial mice are a bit special, since they use different line settings
- etc. So there's a serial 'meta' driver that sets the line characteristics
- to those of each driver in turn.
-
- Currently, I'm able to detect either ps2 or an M$-compatible mouse
- fairly reliably. I haven't tested the logitech code. If you don't jiggle
- the mouse too hard, detection is faster; otherwise, it will start with
- a few false guesses before settling on the right one. Good packets are
- those that can be decoded, have reasonable dx/dy values and no mouse
- button pressed. (this might be improved by looking at the second
- derivative, so to speak: changes in dx/dy values sent by the mouse
- shouldn't be too large).
-
- The question is whether this is really worth the trouble. Maybe we will
- have as high a success rate if we use ps2 when able to open the device;
- and ttyS0 with the M$ protocol otherwise.
-
-